When a client requests a piece of content such as digital video, audio, or some other sampled content from a server, the client typically provides the global address of the content in the form of a Uniform Resource Locator (URL). The server then accesses the content and sends or “streams” it to the client as a continuous data stream.
There are various file formats for streaming media content and composite media streams. “Advanced Streaming Format” (ASF) is an example of such a file format. ASF specifies the way in which multimedia content is stored, streamed, and presented by the tools, servers, and clients of various multimedia vendors. ASF provides a storage and transmission file format that encapsulates multimedia data types. Images, audio, and video as well as embedded text (e.g., URLs), graphic elements, and hyperlinks associated with elements on a Windows Media Player® interface are examples of items, or content that may be so encapsulated. Such file formats provide for the synchronization of these objects within a stream. Further details about ASF (also known as “WINDOWS Media Container Format) are available from Microsoft Corporation of Redmond, Wash.
Regardless of the streaming file format used, an individual data stream contains a sequence of digital data sets or units. The units represent an image, sound, or some other stimuli that is perceived by a human to be continuously varying. The client renders the units individually, in sequence, to reproduce the original stimuli. For example, an audio data stream includes a sequence of sample values that are converted to a pitch and volume to produce continuously varying sound. A video data stream includes a sequence of digitally specified graphics frames that are rendered in sequence to produce a moving picture.
In the simplest case, the client requests a single streaming media file, to play a single piece of content such as a single song or a single video. Alternatively, a client may request a playlist file that includes references to a number of individual streaming media files, or content.
Each playlist file contains information such as whether to play certain pieces of content more than one time, which pieces of content to play, the order in which to play referenced content, and the like. Playlist files contain references to one or more media streams and describe how pieces of media are combined. Playlists do not contain the actual media data, but rather references to the media data. As a result, playlist files are typically small, generally only containing text, and are generally easy and computationally inexpensive to modify. References to a single piece of media may appear in many playlist files.
Table 1 shows an example of a simple playlist.
TABLE 1EXAMPLE OF A SIMPLE PLAYLIST<ASX version = “3.0”><Title>Title</Title><Entry><Ref href = “mms ://nsserver/content/title1.asf”/></Entry><Entry><Ref href = “mms ://nsserver/content/title2.asf”/></Entry><Entry><Ref href = “mms ://nsserver/content/title3.asf”/></Entry><Entry><Ref href = “mms ://nsserver/content/title4.asf”/></Entry></ASX>
Playlist referenced media content can be stored on a Windows Media® server (e.g., mms://ServerName/Path/FileName.asf), a broadcast multicast (e.g., http://WebServerName/Stations/kxyz.nsc), a broadcast unicast that is accessed from a publishing point (e.g., mms://ServerName/PublishingPointAlias), on a Web server e.g., http://WebServerName/Path/Filename.asf), on a network share (e.g., file://\\ServerName\Path\Filename.asf), on a file on a local hard disk drive, and/or the like.
Playlist files have the effect of combining several individual pieces of content into one single complex piece of content, and they are incredibly important to providers of streaming media. They allow content providers to combine advertisements with other content, and therefore build a business based on advertising revenue. They allow Internet radio stations to create a playlist of broadcast songs. They also allow providers to brand their content by attaching previews or radio-station identifiers before or after the content.
For example, if the playlist is a client-side playlist, a script command may be sent to the client in a data stream to instruct Windows Media Player® to cut away from the stream and play other predetermined streams or files according to predetermined playlist/metafile specified scripting in the client-based metafile. This scripting technique can be used for predetermined/specified ad content insertion. To illustrate this, consider that during a live Internet broadcast of a ball game, a script command can be sent at the beginning of every commercial break that instructs each client (e.g., a Windows Media Player®) to play commercials that are already identified in their metafile. When clients finish playing the commercials, scripting in the metafile instructs each client to cut back to the live broadcast.
Playlists are implemented either on a client or on a server such as a WINDOWS Media® server. When the client implements a playlist, the playlist is typically downloaded from a server such as a Web server, a file server, and/or the like. The client interprets the playlist file to present a series of requests to one or more servers to access at least a portion of the content represented in the playlist. A server is generally not aware that the client is requesting content that is referenced in a client-side playlist file. This is because use of a client-side playlist is indistinguishable from a client communicating a number of requests to the server to play several different pieces of content one after the other.
Server-side playlists are maintained by a server and are not downloaded to a client. To access the content represented by a server-side playlist, a client typically selects a URL that identifies a server and a particular playlist. In response, the identified server interprets the playlist to stream the content referenced by the playlist to a client, one piece of content at a time.
Both clients that implement client-side playlists, and servers that implement server-side playlists expect a playlist to be in a predetermined fixed data file format. This is because the playlist must be interpreted, or parsed. To accomplish this, such clients and servers typically include a playlist interpreter that can parse a particular playlist data format. If a playlist is not in the right data format, the server's playlist interpreter will not be able to parse/understand the content of the playlist.
Such a fixed data file format requirement for representing playlists creates a significant problem. Different content providers will often prefer different playlist data formats, and therefore will use different types of playlist interpreters or servers. In many cases, these interpreters are able to recognize and interpret only a single format. This is a problem for a provider that desires to use a different format because the provider is typically forced to choose either a non-preferred format or a non-preferred interpreter. It also makes it difficult for a provider to simultaneously use two or more different playlist formats.
Referring to FIG. 1, there is a block diagram that illustrates the use of a fixed format playlist 104 to represent media content to stream to a client. Streaming data server 102 accepts a fixed format playlist 104. The fixed format playlist must represent its referenced media content in the fixed format expected by server 102. If it is not in the expected fixed format, the content referenced by the fixed format playlist 104 cannot be interpreted, and thus, cannot be streamed by the server to client 110.
There are yet other problems associated with traditional systems and procedures for streaming content using playlists. For example, there is generally no way to impose a policy with respect to the content represented in a playlist without modifying the playlist itself.
This is a problem because policy can change over time and content that may have been contrary to a first policy may be allowable with a second policy. If an original playlist is modified to meet the requirements of the first policy, then the original playlist may need to be regenerated to recapture the excised content to meet the second policy. In addition, modifying a playlist generally requires that an administrator disable the playlist interpreter or server. This is a significant problem for content servers-continuous, uninterrupted availability is an important characteristic to most providers.
There are any number of scenarios that could require the regeneration or versioning of playlists to meet the imposition of policy requirements. Such playlist regeneration and versioning tasks could be very burdensome to program directors, system administrators, and the like.
Yet another problem associated with traditional systems and procedures for streaming data to a client using server-side playlists is that it is not feasible to stream new content in the middle of other content that is already streaming to a client. This is because generating a new streaming media file is computationally very expensive. It means compressing video and/or audio data. For example, to insert an advertisement into the middle of a movie, a new digital movie with the advertisement in the middle of it would need to be created. This is not a practical solution. Ideally, one could stream new content in the middle of other content that is already streaming to a client without needing to regenerate a new streaming media file.